home *** CD-ROM | disk | FTP | other *** search
- July 18th, 2000, the Heskett Ranchette in WV, USA
- With further updates as I swat ever smaller bugs in the 1.00 release
- Last update July 18, 2000 Gene Heskett
-
- This is the version 1.00i upgrade package for registered users prepared by
- Gene Heskett, half of the EzSoft team. Unforch, Jim's machine seems to
- have passed on, so I'm the remaining 'it' for EzSoft :)
-
- cd to your 'EzHome:' assign and unpack this right over the original
- install, or rename the files EzHome and EzHomePrefs by appending their
- version numbers to the name if you'd like to save them for posterity,
- whatever that is.
-
- 1. You will now find that the housecodes that didn't work, now do. You'll
- also note that the housecode in the gui display is actually updated from
- the status data fed back to the gui from the daemon, so that it will show
- properly in the gui even if you grab a shell and give the daemon a command
- like "rx 'address ezhome sethouse p'", even if you do it while the gui
- isn't running. The initial status update the gui asks for will update it
- to the current housecode in both displays.
-
- One thing that may not be readily apparent is that the RealTime page, the
- front page if you will, can issue commands to other housecodes besides the
- one the prefs page is set at. Only by changing it from a cli, or from the
- prefs page, is the cm-11a's actual house monitor updated. I update the
- RealTime page too, unforch without updateing the button labels in the left
- column. That might be in V1.01 if its easily done. The GUI is another
- animal entirely :)
-
- 2. You will now find your registered name is displayed by the about
- requester, the 'house' icon in the upper right corner of the gui being the
- button for that.
-
- 3. Somewhere along the line, the daemons quick mode was commented out, so
- that probably doesn't work. I've never run it that way myself, and it is
- designed to be a background daemon waiting to do your bidding anyway.
-
- 4. Late fixes to the daemon include the detection of the word 'RUNIT' in
- the descriptor portion of the EZHome:prefs/Action.prefs file
- While testing it here, I kept getting guru's from 'SPEAK' because
- it was trying to be a whole committee meeting with several copies
- of talkingclock trying to get to it at the same time. So a new
- 'VARIABLE' has been added. If the function IS safe to run multiple
- copies of itself, then add the keyword 'RUNIT' to the end of the
- description and resave the prefs. If it is not safe to run
- concurrant copies of the command, the daemon will now WAIT for
- the command to execute before continueing. As some commands might
- be lengthy scripts, thereby holding up the daemon till they return,
- it is probably better to have the script set a small file in RAM:
- to indicate to other copies that may be launched that it is already
- running, and if it finds it, before it sets it, it should exit.
- The original copy of course needs to delete that tallying file as
- the last thing it does before quiting. This doesn't actually
- require a lot of code to do. Here is one way to do it.
- -----------------------
- /* AREXX requies the FIRST line to be a comment line */
- /* ARexx script to prevent more than one copy of 'unique_name' from being run */
-
- SIGNAL ON BREAK_C /* make it breakable via ctl-c */
- options results
-
- mytest = 1 /* set this to 0 to run your script or program instead of my test delays */
- runfile = 'ram:unique_name' /* change to suit human readability */
-
- /* most arexx stuff needs this, make sure its already in memory */
- IF ~SHOW('L','rexxsupport.library') THEN CALL ADDLIB('rexxsupport.library', 0, -30)
- IF ~SHOW('L','rexxdossupport.library') THEN CALL ADDLIB('rexxdossupport.library', 0, -30)
-
- IF ~EXISTS(runfile) THEN DO
- ADDRESS COMMAND 'date >'runfile
- IF mytest = 1 THEN DO
- CALL DELAY(1500) /* 30 secs to test the rest of the routine */
- END
- ELSE DO
-
- /* "include" your original arexx script here with your favorite editor
- one could also run something else with the usual
- ADDRESS COMMAND name_of_program (or shell script) to be run here
- */
- END
- END
-
- BREAK_C: /* fall thru to clean house, or if broke with ctl-c */
- ADDRESS COMMAND 'delete >NIL: 'runfile
- EXIT 0 /* all done, quit this instance W/O error */
- -----------------------
-
- 4a! The most recent change is to treat something being sent to itself as
- a RUNIT item regardless of whats in the prefs file comment. Prevents
- lockups in the situation where it is sending a message to itself,
- but waits forever at the send point for a receipt it will never get,
- being stuck at the 'send it' point waiting. This, as of July 2, has
- been fine tuned a bit as I found it was arbitrarily running anything
- located in the EzHome: assign, not what I wanted at all. So it now
- checks the string comparisons against the full 'ADDRESS EZHOME',
- requireing a return of greater than 4 before that behaviour is
- triggered. Since a normal commandline string also is prefaced
- with 'RX "ADDRESS EZHOME"' which returns a 5 when queried with
- POS(search,target) this seems pretty safe. Version is now 1.00h.
-
- 4b! A couple of fixes for a runaway send, and it now logs in 3 places,
- once for an arexx received command, once for a powerline received
- command, and again for a powerline sent command. If the logfile
- level is 2, it also logs Action.prefs about to be done as of V1.00i.
-
- 4c! I've noted that we don't really specify the contents of the file
- "EZHome.prefs", so here is my current one with added comments:
-
- comment line in file content of fileline
- Location to save logfile to 1 sd0:ezhlog.txt
- Serial devices name 2 duart.device
- Serial device unit number 3 0
- Default house code number 4 6
- Logfile detail level 5 2
-
- Just 5 lines, located obviously in the EZHome:prefs directory.
- Line 1-3 are self-explanatory. Here I can run it on the seriel.device
- just as easily, but I had this spare port on my Multiface III since my
- networking uses an ethernet card to my linux box, which still auto-dials
- when this machine wants online :-)
- Line 4 is the housecode as decoded, that 6 equals house A.
- Line 5 if = 1 will cause what it has done to be logged, if 2 will cause
- it to also log what Action.prefs it is *about* to do. This is for
- V1.00i and greater only, a troubleshooting aid. The extra logging will
- slow it down because it will be between the event coming in and the
- actual performance of the Action.prefs event.
- 4d! Un-mentioned are troubleshooting outputs obtainable when ezecuting
- the daemon from a shell. 'ezhome -v' will get you a LOT of output as
- it sort of self traces its execution, including the line number in
- the source code, please report these if possible.
-
- A late addition is a second 'ezhome -s' option which will trace only
- the powerline reception and handling code, and will, when it does a
- readprefs, also output the Ezhome.prefs lines, but only in that code
- built *after* 07-15-2k will the prefs be read back, thats why it
- grew about 80 bytes.
-
- 5. Beat on it and give me feedback please, addressing flowers and flames
- to <gene_heskett@iolinc.net>
-